Summary

Two robustness fixes for the GD32VW553 port:

1. Reject WPA3/SAE networks instead of crashing. Associating to a WPA3
(SAE) network faulted inside the prebuilt vendor supplicant (load access
fault in the elliptic-curve math of the SAE handshake). The port is
WPA2-only, so refuse what the supplicant cannot complete:

• Undefine CONFIG_WPA3_SAE in the build_config.h shim. This activates
  the vendor's own fallback in wifi_netlink.c: the SAE/OWE AKMs are
  stripped from the connection config and the SAE auth algorithm is never
  selected, so a WPA3-transition AP (WPA2/WPA3 mixed) now associates
  through WPA2-PSK. The flag only gates code, not struct layout, so the
  prebuilt libraries are unaffected.
• Refuse an SAE/OWE/802.1X-only network up front in the connect path with
  ENOTSUP and a console message naming the unsupported AKM bitmap,
  instead of an obscure association failure.

2. Restart BLE advertising after disconnection. A connection stops the
legacy advertising set and the vendor stack leaves it stopped, so after the
first central connected (or aborted the attempt) the device was never
discoverable again until a reset. Register a connection callback and
restart the advertising set with ble_adv_restart() on every
disconnection. This covers both the clean disconnect and the
aborted-connection case (an incomplete connection holds the link until the
supervision timeout, whose disconnection event then restarts the
advertising the same way).

3. Make the build warning-clean for CI (-Werror). The board's build carried warnings rooted in the vendor SDK integration; they pre-date this PR (master carries them too) and CI surfaced them here because it builds with -Werror. The NMSIS riscv_encoding.h redefines 32 CSR macros that NuttX's <arch/csr.h> already defines with its own encodings, and no -Wno flag covers macro redefinitions, so the SDK patch now undefines those names right before the NMSIS definitions (same treatment for COMPILE_TIME_ASSERT in wifi_management.h). The remaining vendor-source warnings get matching -Wno suppressions scoped to this chip's build, and the port's own warnings are fixed properly: a CSR name in gd32vw55x_eclic.h that redefined the standard CLIC one, an unused variable and a dead function. Diagnostics only -- no behavior change

Impact

Only the GD32VW55x port (arch/risc-v/src/gd32vw55x and its board
documentation); no common code is changed. Behavior changes:

• A WPA3-transition network now associates through WPA2-PSK (it previously
  crashed the supplicant).
• A WPA3(SAE)-only network is refused with ENOTSUP and a clear console
  message (it previously crashed the supplicant).
• The BLE device stays discoverable across connections (it previously
  required a reset after the first connection).
• The warning cleanup changes no behavior: the vendor sources already used the NMSIS macro values (the redefinition always won), and the removed code was dead.

Testing

Built the wapi and ble configurations; nxstyle is clean. Validated
on hardware (GD32VW553K-START).

./tools/configure.sh gd32vw553k-start:ble   # wapi + BLE, exercises both fixes
make -j
openocd -f openocd_gdlink.cfg \
        -c "program nuttx.bin 0x08000000 verify reset exit"

1. WPA2 network (regression: still associates)

nsh> ifup wlan0
nsh> wapi psk wlan0 ******** 3
nsh> wapi essid wlan0 @GUZM 1
[0] (-29 dBm) CH=  1 BSSID=XX:XX:XX:XX:XX:XX SSID=@GUZM  [RSN:WPA-PSK CCMP/CCMP]
MAC: auth req send
MAC: auth rsp received, status = 0
MAC: assoc req send
MAC: assoc rsp received, status = 0
WPA: 4-1 received
WPA: 4-2 send
WPA: 4-3 received
WPA: 4-4 send
nsh> renew wlan0
nsh> ping -c 3 8.8.8.8
PING 8.8.8.8 56 bytes of data
56 bytes from 8.8.8.8: icmp_seq=0 time=21.0 ms
56 bytes from 8.8.8.8: icmp_seq=1 time=44.0 ms
56 bytes from 8.8.8.8: icmp_seq=2 time=11.0 ms
3 packets transmitted, 3 received, 0% packet loss, time 3003 ms

2. WPA3(SAE)-only network: refused with a clear error, no crash

Phone hotspot wpa3test configured as WPA3-Personal (SAE only):

nsh> wapi psk wlan0 12345678 3
nsh> wapi essid wlan0 wpa3test 1
gdwifi: 'wpa3test' offers no supported AKM (bitmap 0x200): WPA3/SAE, OWE and 802.1X are not supported, WPA2-PSK only
nsh> echo ALIVE
ALIVE

(Before this change: EXCEPTION: Load access fault in the wifi_mgmt
task. 0x200 is bit 9 = MAC_AKM_SAE. A refused connect also leaves a
previously established association untouched.)

3. WPA2/WPA3 transition network: associates through WPA2-PSK

Same hotspot switched to WPA2/WPA3 mixed mode; note the SAE AKM and MFP in
the beacon, and the plain WPA2 four-way handshake used:

nsh> wapi essid wlan0 wpa3test 1
[0] (-37 dBm) CH= 11 BSSID=XX:XX:XX:XX:XX:XX SSID=wpa3test  [RSN:WPA-PSK,SAE CCMP/CCMP][MFP:AES-128-CMAC]
MAC: auth req send
MAC: auth rsp received, status = 0
MAC: assoc req send
MAC: assoc rsp received, status = 0
WPA: 4-1 received
WPA: 4-2 send
WPA: 4-3 received
WPA: 4-4 send
nsh> renew wlan0
nsh> ifconfig wlan0
wlan0	Link encap:Ethernet HWaddr XX:XX:XX:XX:XX:XX at RUNNING mtu 1500
	inet addr:10.28.126.72 DRaddr:10.28.126.23 Mask:255.255.255.0
nsh> ping -c 3 10.28.126.23
3 packets transmitted, 3 received, 0% packet loss, time 3003 ms

(Before this change this case also crashed: the supplicant selected SAE
whenever the AP offered it.)

4. BLE: repeated connect cycles from a Linux central (bleak)

Scan / connect / write / disconnect cycles, no board reset in between:

[cycle 1] advertising
[cycle 1] connect+write+disconnect OK
[cycle 2] advertising          <- re-advertising after the clean disconnect
[cycle 3] advertising          <- re-advertising after an aborted connection

Board console receives the writes:

nsh> BLE RX (7): final 1

(Before this change the device was no longer advertising after the first
connection and never became discoverable again until a reset.)